fix(egress): single composite fanning out to all destinations#20
Merged
Conversation
One isolated egress per RTMP destination (b3860a1) duplicated the whole headless-Chrome render + H264 encode per platform, so Twitch + YouTube needed ~2x CPU. The 4-vCPU SFU droplet thrashed (load ~9): the second composite (YouTube) starved and hung on "Preparing", and the startup CPU spike delayed the host publisher's DTLS handshake server-side, surfacing as "could not establish pc connection". Collapse back to a single RoomComposite carrying every URL in one StreamOutput: one render + one encode regardless of platform count, each extra URL just a cheap mux. ~2.0 CPU, fits 4 vCPU. keyFrameInterval:1 already mitigates the YouTube-"Preparing" back-pressure the split targeted. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Streaming to Twitch + YouTube at once: Twitch works, YouTube hangs on "Preparing stream", and the host intermittently gets "could not establish pc connection".
Root cause is a single CPU ceiling. The previous commit (
b3860a1) started one isolated egress per RTMP destination, which duplicates the entire headless-Chrome render + H264 encode pipeline per platform. Two platforms = ~2× CPU; the 4-vCPU SFU droplet thrashed (load ~9):Confirmed live in the SFU logs: load average 9.16 on 4 cores, four
StartRoomCompositeEgress(Chrome) participants across overlapping sessions; publisher hitdtls timeoutthen reconnected via TURN.Fix
Collapse back to a single
RoomCompositecarrying every URL in oneStreamOutput. One render + one encode regardless of platform count; each extra URL is just a cheap mux. ~2.0 CPU — fits 4 vCPU comfortably.keyFrameInterval:1(unchanged) already mitigates the YouTube-"Preparing" back-pressure that motivated the per-destination split.Only
start/route.tschanged;stoproute and desktop already flattenegressIds[], so they're compatible with the single-element array.Trade-off
With one shared composite, a hard stall on one platform can back-pressure the other — the thing the split prevented. In practice
keyFrameInterval:1already fixed the actual trigger (YouTube "Preparing"). If both platforms and hard isolation are needed later, that's the case for an 8-vCPU (ideally dedicated-CPU) droplet.Test
route.test.tsupdated to assert a singlestartRoomCompositeEgresscall carrying both URLs. 4/4 pass.🤖 Generated with Claude Code